Conversation
|
Warning Rate limit exceeded
Your organization is not enrolled in usage-based pricing. Contact your admin to enable usage-based pricing to continue reviews beyond the rate limit, or try again in 56 minutes and 42 seconds. ⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Run ID: ⛔ Files ignored due to path filters (2)
📒 Files selected for processing (3)
📝 WalkthroughWalkthroughVersion bump from 2.1.20 to 2.1.21 across workspace metadata and package configuration, coupled with significant enhancements to the CI publish script to support readme metadata in wheels, implement concurrent PyPI uploads via thread pooling, and add post-upload verification. Changes
Sequence DiagramsequenceDiagram
participant CI as CI/Publish Script
participant Pool as Thread Pool
participant PyPI as PyPI (uv publish)
participant API as PyPI JSON API
participant Out as Output/Logs
CI->>CI: Load wheels from dist/wheels/
CI->>CI: Build task queue (per wheel)
CI->>Pool: Submit concurrent upload tasks
loop For each wheel
Pool->>PyPI: uv publish --check-url WHEEL
PyPI-->>Pool: Success/Failure + output
Pool-->>Out: Log recent output lines
end
Pool-->>CI: All results aggregated
alt Any upload failed
CI->>Out: Exit with failure
else All uploads succeeded
CI->>API: Query PyPI JSON API
API-->>CI: Return published filenames
CI->>CI: Verify expected wheels present
alt Verification passed
CI->>Out: Confirm publication success
else Verification failed
CI->>Out: Exit with verification error
end
end
Estimated code review effort🎯 4 (Complex) | ⏱️ ~45 minutes Poem
🚥 Pre-merge checks | ✅ 2 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
2.1.20 shipped with mode=0o755 on the `fbuild` / `fbuild-daemon`
console scripts but with external_attr=0x01ed0000 — i.e. the mode
bits were set correctly but the file-type bit (S_IFREG) was zero.
pip's wheel installer calls stat.S_ISREG() on the upper 16 bits of
external_attr before deciding whether to apply the script's mode;
without the IFREG bit that test returns False, pip falls back to
umask defaults (0o644), and the binary lands on disk without +x:
/opt/hostedtoolcache/Python/3.12.13/x64/bin/fbuild:
Permission denied (exit code 126)
Windows doesn't care about exec bits on .exe files, which is why
2.1.20 looked fine on `uv tool install fbuild==2.1.20` on Windows
but was broken for every Linux/macOS user. It's also the root
cause of #129 — #135's "preserve exec bit" fix set
the mode but not the file-type bit.
Reference: uv / ruff / maturin-built wheels all have
external_attr=0x81ed0000 (S_IFREG | 0o755) on their script entries.
Verified locally by rebuilding the Linux x86_64 wheel against the
existing binary artifact: new external_attr=0x81ed0000, IFREG=True.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2.1.20 is stuck on PyPI with unusable Linux/macOS wheels (missing S_IFREG on `fbuild` / `fbuild-daemon` script entries → `Permission denied` on every non-Windows install). The fix from the previous commit only takes effect on a fresh release; PyPI does not allow overwriting an existing version's wheel filenames. Release notes vs 2.1.20: - fix(publish): set S_IFREG on wheel script entries so pip applies +x to bundled binaries on Linux/macOS - fix(publish): per-wheel concurrent upload with post-upload verification, so partial uploads never silently succeed Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
1.2.12 is the last zccache release that ships broken Linux/macOS wheels — the bundled `zccache` binary lacks +x and every cache operation fails with `Permission denied`. The upstream fix landed in zccache 1.2.13 (zackees/zccache#35: S_IFREG + create_system=3 on wheel script entries). Bumping the floor so fresh pip installs of fbuild 2.1.21 don't pin themselves to a broken zccache. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The fbuild PyPI project page has been blank because the hand-built wheels' METADATA only carried the four required headers (Name, Version, Summary, Requires-Python) with no description body. PyPI falls back to the project's one-line summary when no description is present, so users landing on pypi.org/project/fbuild/ saw one line of text instead of the README. - Add `readme = "README.md"` to `[project]` in pyproject.toml so standard packaging tools (and the inspection snippet below) can discover the README file without guessing. - Teach `read_project_meta()` to load the file when present. - Extend wheel METADATA with `Description-Content-Type: text/markdown` and the README body, per PEP 566. fbuild's Rust crates are not published to crates.io (no `cargo publish` in `ci/publish.py`, no PUBLISHABLE_CRATES list, and none of `fbuild-core`, `fbuild-cli`, etc. exist on crates.io), so no Cargo.toml `readme = "README.md"` lines are needed here. Rides with 2.1.21. Verified: rebuilt the Linux x86_64 wheel locally, METADATA now contains the Description-Content-Type header and a 24 KB markdown body. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
zackees
force-pushed
the
fix/publish-script
branch
from
2bd0285 to
6652ae5
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary by CodeRabbit
Chores
New Features
Bug Fixes